1. Field of the Invention
This invention relates generally to computer programming, and more particularly, to dynamically placing resources within a graphical user interface (GUI).
2. Background Information
Generally, computers have had many different uses and/or purposes, such as for performing calculations, word processing, data storage, etc. Computers normally have a means for processing data, a means for displaying data, and means for inputting data. An example computer may take the form of a personal computer (PC) or other device, such as a peripheral device (e.g., handheld devices, etc.). Until recently, people have interfaced with computers primarily utilizing text-based interfaces, or Command Line Interfaces (CLIs). In a CLI, a user inputs text-based commands to the computer based on one or more programming languages (e.g., a disk operating system, or DOS language, etc.) using a keyboard. The computer then responds according to the inputs and returns a computed result on the display.
Because of the many different commands available to a user, and the often difficult learning curve associated with CLIs, today's computers often utilize what is known as a Graphical User Interface (GUI). A GUI is an operating system interface based on graphics, rather than (or in addition to) text. Typically, a mouse or other tracking device is used to select between any number of objects or icons (e.g., buttons, scroll bars, images, entry fields, etc.), or “resources,” shown on the display. Each of the resources represents a different command to the computer, which responds according to the user's resource selection. For instance, instead of typing a command to operate an executable program, e.g., typing “run program.exe” into a command line, a user of a GUI may simply point to the icon representing the program, and select the icon (e.g., by “clicking” the mouse). The computer then responds accordingly (i.e., operating the program). A common example of a GUI for use with PCs is the Microsoft® Windows® operating system.
Also, as those skilled in the art will understand, one or more GUIs for specific applications/programs may be displayed within other GUIs (e.g., a program running in Windows® may also be a GUI). Further, in addition to being used for PCs, GUIs may also be used for specifically designed devices. For example, handheld devices used for various task-related purposes may have specifically-integrated GUIs designed for performing that task (e.g., tracking packages, etc.).
The creation of a GUI begins with development of the GUI's software or code, typically by one or more software developers. The software developers, using a selected GUI programming language, design the overall layout and functionality of the GUI based on techniques understood by those skilled in the art. For instance, the software developers create and/or use a variety of resources (images, buttons, icons, etc.), and associate each of the resources with a plurality of properties. Those properties generally comprise, e.g., a command/control/action to perform in response to selection of the resource, a location or position of the resource, a size of the resource, a font for any text of the resource, etc. Each resource is also given a name (e.g., “resource1.jpg”), and may be stored in a memory, such as a non-volatile memory or “file store,” for use with the GUI (.jpg is a JPEG image file extension, as will be understood by those skilled in the art). Also, the resource may be stored in a database or within the executable as an embedded resource, as will be understood. A programming language many software developers currently use to create GUIs is Visual Basic® (VB) available from Microsoft®.
To assist with the layout and appearance of the GUI, software developers often enlist the services of graphic designers to graphically design visuals for the resources (e.g., create images for the icons, buttons, etc.), and to determine an appropriate position for the resource within the GUI. For instance, based on the desired functionality, a graphic designer may be asked to create the overall layout of a GUI, such as a background, images to be used for each resource, placement of the resources, etc., thus creating a graphical image of the GUI.
Once the overall GUI image is created, the graphic designer may “cut” the image for each resource from the overall image, and save the respective cut images with agreed filenames for the corresponding resources. For example, the image of a “help” icon within the GUI may be cut and saved as “help.jpg.” The graphic designers may then provide the software developer with the saved image for the particular resource (e.g., by saving it in the file store), and further provide the software developer with the position information regarding the resource. For instance, if the “help” resource was located at coordinates of 50 pixels in the “X” direction (“50X”), and 50 pixels in the “Y” direction (“50Y”), the graphic designer informs the software developer of this location (e.g., “50×50”). The software developer may then enter the position information of the resource (e.g., “help.jpg”) into the GUI code, along with other necessary parameters (properties) of the resource, such as what action should be taken as a result of the selection of is the resource (e.g., enter a “help menu”). Notably, an example program that may be used by graphic designers to create and cut the image is Adobe Photoshop®. The end result is a GUI that may be generated by executing the GUI generating code (e.g., the “executable”), which reads the data for the resources (e.g., the images) from the file store, places the resource images according to the code, and associates resource parameters accordingly.
One problem with the above arrangement between the software developer and the graphic designer is that the graphic designers often change the layout of the GUI during development (and afterward), e.g., to move resources from one location to another (and/or to change the image associated with the resource). For example, assuming the “help.jpg” resource was originally located at 50×50 as mentioned above, the graphic designer may wish to change the location to 100×50 (i.e., moving the resource 50 pixels in the “X” direction). As a result, the graphic designer informs the software developer of the position information change for the resource, and the software developer re-enters the code to change the appropriate parameters (i.e., the position). If the graphic designer again changes the position, once more, the software developer must re-enter the code to adjust the parameters accordingly. This “back-and-forth” between the graphic designer and software developer wastes valuable time and resources for those involved.
FIG. 1 is a flowchart illustrating an example of an inefficient procedure for developing a GUI described above. The procedure 100 starts at step 105, and continues to step 110, where a software developer develops code for the GUI, as will be understood by those skilled in the art. At step 115, a graphic designer graphically designs a resource, e.g., an image (e.g., “help.jpg”), for the GUI, and at step 120, determines the position of the resource within the GUI (e.g., 50×50). The graphic designer then saves the resource in the file store for insertion into the GUI at step 125 (e.g., for when the GUI is generated), and informs the software developer of the resource's position in step 130. The software developer then programs the code of the GUI to place the resource in the corresponding position in step 135. GUI creation software (a “GUI executable”) may graphically display (create) the GUI accordingly in step 140, and if there are no changes to the resource's position in step 145, the procedure ends at step 150. In the event, however, the is graphic designer should decide to change the position of the resource (e.g., during the development of the GUI) in step 145, the designer must inform the software developer of the new position (e.g., 100×50) in step 130. The software developer must then reprogram the GUI to place the resource in the new position in step 135.
As mentioned, the graphic designer may often change the position of a resource during development of the GUI, and the back-and-forth between the designer and the software developer of steps 130 through 145 becomes a major inefficiency in the development process. There remains a need, therefore, for a technique that allows software developers and graphic designers to more efficiently collaborate on the placement of resources during the development of a GUI. In particular, there remains a need to substantially eliminate the back-and-forth involved with changing the position of the resources.